In communications networks, data, voice and video may be transported in data frames. A data frame consists of a variable number of ordered octets. The boundaries of the frame are delimited by some protocol, e.g. HDLC, on a physical communication medium. For purposes of this discussion "data frame" refers to the logical level, i.e., after the contents of the frame have been extracted from the envelope. In the networks, or at the edges of the networks, the data frames are input to and output from various network devices, such as routers and frame relay switches, through the frame I/O of the devices. The devices include protocol applications, such as HDLC, X.25, Frame Relay, Ethernet, etc., which perform various operations on the data frames, e.g., reading and writing, in order to manipulate the data frames according to the particular protocol, as is well known in the art.
When the data frames are received by a network device, the frame I/O removes the envelope and buffers the contents of the data frame in the data frame I/O buffer structure. The protocol applications then perform various functions on the data frames while they are stored, in the buffer structure. The simplest representation of a stored data frame is an array of octets stored in contiguous memory. With this representation, size of the memory must be large enough to hold the largest legal frame supportable by the protocol applications being served. Unfortunately, this representation is not the typical representation of a data frame. The typical representation of a data frame involves a buffer structure comprised of an ordered set of buffers, wherein each buffer contains an array of octets, but the size of the buffer is less than the maximum legal length frame.
The primary reasons for using the second representation is because the frames are typically maintained in memory for some period of time, rather than being immediately disposed of, and because there is usually a substantial difference between the maximum legal length frame and the average legal length frame. Thus, a significant amount of memory space can be saved. If a buffer structure having multiple buffers is not used, any time a data frame is to be received, the frame receiving hardware in the frame I/O must be provided with sufficient memory space to receive the largest legal frame.
The protocol applications perform various operations on the data frames, e.g., reading and writing, in order to manipulate the data frames (particularly the headers of the data frames) according to the particular protocols. In order to avoid copying of data frames by the protocol applications when manipulating the data frames, which impedes device performance, typically the details of the buffer structure of the frame I/O are shared with the protocol applications. This allows the applications to examine or modify the data in the data frame without requiring the applications to copy the contents of the data frame. This approach, however, is less than ideal, as the code that implements the protocol application must be entangled with the details of the scheme of a particular buffer structure. Buffer schemes are relatively complex and therefore it is rare to find different buffer implementations with compatible schemes. As a result, the protocol applications are generally not compatible with buffer implementations having different buffer schemes than the implementations and schemes with which the applications were designed to operate and therefore are not readily portable to devices having different buffer implementations.
Accordingly, a need exists for a frame I/O interface which avoids frame copying by protocol applications, yet isolates the buffer structure of the frame I/O from the protocol applications. This will allow much greater flexibility in using protocol applications with data frame I/Os having various buffer structure schemes while maintaining device performance.